Flag table overpromises vs. the shipped SKILL.md. This table presents six flags as required / always used, but the embedded skill — the artifact a reader actually installs and the agent follows — only mandates two: its Discovery section marks --replay-source smart-set and --freezeTime as MANDATORY, and the A4/B4 replay commands show only those. --cluster, --branch-name, --disableReportUpload=false, and --strict-failure appear nowhere in the skill.

Result: an installed agent omits --cluster and hits the exact no active clusters found error this table warns about, or omits --disableReportUpload=false and the run never shows on the dashboard — contradicting "the agent always uses." Fix by adding the four flags to the skill's replay invocations, or soften this table to "recommended."

Fixed by making the skill match the table (your first option). The embedded skill's Discovery now carries a single canonical replay command that lists all the flags the table promises:

keploy cloud replay --app <ns.deployment> --branch-name <git branch> --cluster <origin.clusterName> --replay-source smart-set --freezeTime --disableReportUpload=false --strict-failure

…and A4/B4 now say "replay with the canonical command from Discovery (all flags)" instead of showing only --replay-source/--freezeTime. So an installed agent uses --cluster (no more no active clusters found) and --disableReportUpload=false (run shows on the dashboard) — the "always uses" table is now true. bcc6b64.

Verify the .cursor/skills/ auto-load claim. Cursor's documented project-context mechanism is .cursor/rules/*.mdc (project rules); a .cursor/skills/SKILL.md directory that auto-loads isn't a known Cursor convention. If it's wrong, Cursor users follow these steps and the skill never auto-invokes. Please confirm against current Cursor docs; if unsupported, point them at .cursor/rules/ (.mdc) instead. The Claude Code path below (.claude/skills/smart-set/SKILL.md) is correct.

Verified — the path is correct, and I added the doc link so readers can confirm. .cursor/skills/<name>/SKILL.md is Cursor's Agent Skills mechanism (auto-discovered from .cursor/skills/), documented at https://cursor.com/docs/context/skills — distinct from .cursor/rules/*.mdc (always-on project rules), which is the older convention you're thinking of. It also matches the existing k8s-proxy-llm-workflow doc (which uses .cursor/skills/keploy/SKILL.md and makes the same skills-vs-rules distinction), and it's the path the validation runs actually loaded via cursor-agent. Updated the Cursor section to link the docs and call out the skill-vs-rules distinction. bcc6b64.

Meta-tool list is inconsistent with the rest of this PR. Here the meta-tools are listed as four — get_auth_status, search_tools, get_tool_schema, invoke_tool — but the two legacy pages this same PR edits both list five, including get_setup_instructions:

• agent-test-generation.md: get_auth_status, get_setup_instructions, search_tools, get_tool_schema, invoke_tool
• k8s-proxy-llm-workflow.md: same five.

The failure mode is concrete: this rule keys the whole tool-search detection on "if your tool list shows only the meta-tools." If the server actually exposes get_setup_instructions too, an agent comparing against this 4-item set sees an unexpected extra tool and can misclassify the state. Please align this list to the canonical five.

Aligned to the canonical five. Hard rule 0 now lists get_auth_status, get_setup_instructions, search_tools, get_tool_schema, invoke_tool — matching both legacy pages. I also keyed the detection on "and none of the Smart-set names below" rather than an exact-set match, so if the server exposes an extra always-visible onboarding tool the agent still classifies correctly (keys off the absence of the domain tools, not the exact meta count). af641cb.

--freezeTime is listed under a table titled "Replay flags the agent always uses" but described as conditional ("Required when the app is built with the Go faketime agent"). The SKILL.md compounds this: Discovery step 4 hardcodes --freezeTime into the canonical command and says "use ALL these flags on every replay", then parenthetically re-qualifies it as faketime-only. Net effect for an agent following the literal instruction: it passes --freezeTime on every replay, including apps not built with faketime. Either (a) state that --freezeTime is a no-op / harmless when the app isn't faketime (so "always" is safe), or (b) move it out of the "always" set and gate it on the faketime condition in both the table and the SKILL. Right now the doc tells the agent two different things.

Fixed the contradiction by treating --freezeTime as conditional everywhere (your option b). Dropped the table title 'Replay flags the agent always uses' → 'Replay flags', the intro now says 'required on every replay — except --freezeTime, which is added only when the app is built with the Go faketime agent', and the skill's canonical command shows it bracketed ([--freezeTime]) with 'drop --freezeTime for non-faketime apps' + 'ONLY when … (omit it otherwise)'. The agent is no longer told to pass it unconditionally. af641cb.

Nit / consistency: the body shows keploy record --sync --disable-mapping=false with no command to run, while SKILL.md B2 correctly shows keploy record -c "<cmd>" --sync --disable-mapping=false. A reader copying this line literally records nothing. Suggest matching the SKILL: include -c "<cmd>".

Good catch — fixed. The body now shows keploy record -c "<run command>" --sync --disable-mapping=false, matching SKILL.md B2. A literal copy now actually runs the app. af641cb.

Minor: listBranches is listed in the tool-name set, but no routine uses it — Discovery resolves the branch via create_branch (find-or-create) and caches branch_id. If it's genuinely unused in these routines, drop it to keep the name list tight (every name here is something you're telling the agent to fetch a schema for).

Dropped listBranches from the name list — you're right, no routine uses it (the branch is resolved via create_branch find-or-create and cached). The list is now exactly the tools the routines fetch. af641cb.

The upload command here uses --branch <git branch>, but every replay command on this page uses --branch-name (flags table L105, canonical command L155). Same page, two spellings of the branch flag. If keploy upload test-set really takes --branch while keploy cloud replay takes --branch-name, a half-sentence noting the difference would prevent a reader from reading it as a typo. If they should match, this is a bug.

Confirmed real, not a typo — verified against the CLI:

keploy cloud replay --help → --branch-name (scope to a Keploy branch; --branch here is a CI test-data field)
keploy upload test-set --help → --branch (UUID or name, find-or-create; no --branch-name)

So replay scopes with --branch-name and upload with --branch — different subcommands, different flag designs. Added a 'Flag-name asymmetry (not a typo)' note on the --branch-name row so nobody 'fixes' it. 37c97bc.

This says the listed flags "are required on every replay," but the table omits --app <ns.deployment>, which the canonical command (L155) and Routine B both pass. Suggest either adding an --app row or rewording to "the smart-set-specific flags" so the table doesn't read as the complete required set.

Added an --app <ns.deployment> row to the table — it's required by every replay (and upload), it was just only shown in the canonical command. The intro's 'required on every replay' now matches the table. 37c97bc.

Inconsistent case labels. The classification list mixes a number with letters: Case 1 — App regression, then Case A, Case B, Case C. That ordering reads as a typo and diverges from the "How it works" section above, which uses clean parallel names (Regression / Value drift / Shape drift / Mock drift).

Suggest renumbering consistently — e.g. Case 1–4 — or, better, reuse the same four labels as the prose section so the SKILL.md and the page narrative line up one-to-one.

Tool names here are bare, but the companion doc warns they vary by editor. Hard rule 0 lists exact names (listApps, create_branch, …) and instructs the agent to fetch schemas via get_tool_schema({names:[…]}). The legacy quickstart/k8s-proxy-llm-workflow.md Hard rule 0 explicitly cautions that names differ per client (keploy-<tool> or mcp__keploy*__<tool>).

An agent in Cursor whose tools surface as keploy-listApps would pass the wrong literal to an exact-name get_tool_schema call and get nothing back. Worth adding the same per-editor caveat here, or a line pointing to search_tools(query) as the fallback when an exact name misses — otherwise this skill silently assumes the unprefixed naming.